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(54) A programmable telecommunications interface for communication over a data network 



(57) A telecommunications system includes the 
public switched telephone system (PSTN) and a data 
network (6), such as the Internet. Voice over IP (VoIP) 
boards (48) communicate between the PSTN and the 
data network (6) under control ol a programmable serv- 



ice logic execution environment (12). Telephone servic- 
es between and among the Intemet (6) and the PSTN 
can be inrtiated by a JAVA applet. By packetizing the 
PSTN bearer channel, enhances resources can be pro- 
vided, such as sophisticated conferencing, speech-to- 
text, e-mail to voice, and so on. 
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Description 

[0001] This invention relates in general to telecommu- 
nlcalions and, more particularly^ to a programmable tel- 
ecommunications interface. 

[0002] H.323 is a multimedia communications proto- 
col which promises to have a significant impact on many 
multimedia applications, such as videoconferencing, In- 
ternet telephony, conference calling, and gaming, to 
name a few. The H.323 standard provides support for 
audio and video over IP (Intemet Protocol) based net- 
wurks, as well as foi data coinniunicatiuns. The liilytnel 
is one such data network which will benefit from H.323. 
[0003] H.323 provides compatibility between devices 
which would otherwise be subject to proprietary solu- 
tions. For example, H.323 specifies standards for audio/ 
video compression and decompression and for commu- 
nicatinq device capabilities, common call setup and call 
control. H.323 supports conferences of three or more 
endpoints without required use of a multipoint control 
unit and supports multicast transport in multipoint con- 
ferences. Further, the bandwidth of audio and video 
streams can be managed by network managers. 
[0004] Despite the advantages of H.323 devices, is- 
sues remain. In order to support an H.323 compliant net- 
work, a number of communications devices must be de- 
signed. Rapid service development and deployment of 
these devices is therefore an important challenge to the 
communications industry. Further, like many standards, 
H.323 will likely evolve overtime or may be supplanted 
by other protocols. In either case, reprogramming the 
H.323 devices could be extremely costly and time con- 
suming. 

[0005] Further, while H.323 provides protocols for 
communicatk>ns over a data network, digital telephone 
remains primitive and difficult for users. 
[0006] Therefore, a need exists in the industry en- 
hanced telephony using a digital multimedia protocol. 
[0007] According to a first aspect of the present inven- 
tion, a telecommunications system comprises: a public 
switched telephone system: 

a data network; 

interface circuitry coupled between said public 
switched telephone system and said data network 
for translating between analog voice signals and a 
stream of packet ized voice signals; and, 
circuit circuitry coupled to said public switched tel- 
ephone network and said data network to control 
communication within and between said public 
switched telephone system and said data network. 

[0008] According to a second aspect of the present 
Invention, a service control point for use with a multime- 
dia communicatk>n protocol comprises: 

a database; 

a database manager coupled to said database; 
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a programmable execution unit coupled to said da- 
tabase manager; and, 

a language server coupled to the programmable ex- 
ecution unit to communicate with applications exe- 
5 cuted on client terminals coupled to said language 

sen/er via a data network. 

[0009] The invention provides significant advantages 
over the prior art. First, the use of a programmable serv- 
10 ice togic execution environment (SLEE) in the network 
devices provides for rapid development anddeployment 
uf pioducts and fci flexible irnpleinenlallon uf set vices. 
Second, the invention can be used to gain control of tel- 
ephone calls, even those originating and/or terminating 
15 on the PSTN, in a digital domain. One particular embod- 
iment of the capability would be in conference calling, 
where callers could control the conference via a web 
browser. This would enable callers to have private con- 
versations with another conference caller, and so on. 
while the conference was ongoing, even if one or more 
of the participants was connecting through the PSTN. 
The services are seamless to the users, who have the 
same functionality whether independent of whether 
lines of communication originate or terminate on the In- 
ternet or the PSTN. Third, telephony services can be 
initiated via JAVA applets (or a similar software struc- 
ture, which is preferably processor independent) which 
can enhance and simplify telecommunications services 
to users. 

[0010] Examples of the present invention will now be 
described in detail with reference to the accompanying 
drawings, in which: 

Figure 1a illustrates a block diagram of an IN (Intel- 
ligent network) controller coupled to a network, 
such as the Internet, and the PSTN; 
Figures 1b and 1c illustrate functional bbck dia- 
grams of an SCP; 

Figure 2 illustrates a functional block diagram of a 
gatekeeper; 

Figure 3 illustrates a functional block diagram of a 

gateway; 

Figure 4 illuslrales a block diagram of a telecommu- 
nications system using the gatekeeper and gate- 
way of Figures 2 and 3; 

Figure 5 Illustrates a functional block diagram of an 
ISN device; 

Figure 6 illustrates a functional block diagram of an 
IP device; 

Figures 7a -d illustrate a flow diagram of a call center 

application with associated browser screens; and, 
Figure 8 illustrates a function block diagram of an 
SMS. 

[0011] Figure la illustrates a block diagram of a tele- 
communications network, where intelligent network (IN) 
services can be applied to both a network, such as the 
Internet, and the public switched telephone network 
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(PSTN), including both wireline and wireless services. 
In Figure la, the PSTN and Ihe Internet, or other data 
network (hereinafter Internet/Data Network 6) are cou- 
pled via a gateway 7, such as a H.323 Interlace or other 
suitable interface. An IN controller 8 is coupled to both 
the IntemetyData Networks and the PSTN. The IN con- 
troller B is coupled to the Internet/Data Network 6 by a 
TCP/IP or other suitable connection and to the PSTN by 
an SS7 or other suitable connection. 
[0012] The architecture shown in Figure la can pro- 
vide enhanced sen/ices to both the Internet/Data Net- 
work 6 and lu Ihe PSTN. The IN CunUollei 8 provides 
programmable services to both the Internet/Data Net- 
work 8 and the PSTN (and to communications between 
the two) using asynchronous messaging with a pro- 
grammable state machine, and a service log ic execution 
environment (SLEE). As described in greater detail be- 
low, this architecture provides intra-PSTN communk:a- 
tions, intra-lnternet/Data Network communications and 
inter-PSTN-lnternet/Data Network communications 
with enhanced functionality which is seamless and 
transparent to the users. The IN Controller 8 allows IN 
services to be applied to the Internet, and provides en- 
hanced services to the PSTN by controlling operating 
on the bearer channel of the PSTN while it is packetized. 
[001 3] Figure 1 b illustrates a functional block diagram 
of a preferred embodiment of a service control point 
(SCP) 10 used in conjunction with an H.323 protocol, or 
other multimedia communication protocol. The SCP 10 
comprises a SLEE 1 2. database manager 1 4. Web serv- 
er 1 6 and a JAVA server 1 7 and a Domain Name server 
18. The SLEE sends and receives infomTation via a 
standard TCAP (Transaction Capabilities Application 
Part ) message over SS7 (Signaling System 7) line 20 
and via a TCAP message over TCP/IP line 22: The 
SLEE 1 2 communicates with the database manager 14. 
Web Server 16 and JAVA server 17. The Web server 16 
and JAVA server 17 communicate wrth the database 
manager 14 and the domain name server 18. The Web 
server 16 and JAVA server 17 also communicate with 
browser (communication) software 26 over the Internet/ 
Data Network 6. 

[0014] In operation, the functional block diagram of 
Figure 1 can be implemented on one or more comput- 
ers, such as SUN Solaris computers. The database 
manager, could be, for example, the SYBASE database 
manager. The SLEE 12 is preferably a programmable 
SLEE. Programmable SLEEs are discussed in detail in 
U.S. Sen No. 08/917.674, entitled "System and Method 
tor Communicating Transaction Capabilities Application 
Part Information" to Lin el al, filed August 21 . 1997 and 
U.S. Ser. No. 08/918,693 entitled "System and Method 
for Implementing Transaction Capabilities Application 
Part Communicatbn Protocol" to Lin et al, filed August 
21, 1997. both of which are incorporated by reference 
herein. The U.S. Ser. Nos. 08/917.674 and 08/917,693 
patents relate to a programmable TCAP SLEE. A pro- 
grammable ISUPfTCAP SLEE is described in U.S. Ser. 



No. 09/317,347. filed May 24. 1999. entitled "AIN/IN 
SSP Extension Product" to Stevens el al (based on pro- 
visional application Ser. No. 60/(D86,971. entitled "AIN/ 
IN SSP Extension Product' to Stevens el al, filed May 
s 28, 1 998), which is also incorporated by reference here- 
in. 

[0015] The purpose of the SLEE is to execute previ- 
ously created service logic programs (SLPs). The SLP's 
provide telephony services, which can be initiated 

10 through the Internet using JAVA applets. A programma- 
ble SLEE uses message definition files which define all 
available messages in an editable file. The message 
definition files can be easily modified to accommodate 
modifications and additions to a protocol. In U.S. Ser. 

15 No. (provisional application Ser. No. 

60/086,971). referenced above, the SLEE uses both a 
TMD file (TCAP message definition file) for messages 
received in TCAP and an IMD file (ISUP message def- 
inition file) for messages received in ISUP 

20 [0016] The combination of a programmable TCAP 
SLEE 12 and a database manager 14 is sold as the IN- 
FUSION SCP by DSC Communications Corporation of 
Piano. Texas. 

[0017] The Web server 16 and JAVA server 17 could 
be implemented on the same computer as the SLEE 1 2 
and/or the database manager 14, or could be imple- 
mented on a computer connected to one or more other 
computers performing the tasks of the SLEE 1 2 and the 
database manager 14. In an alternative embodiment 

30 shown in Figure 1c. the Web server 16 is remote from 
the computer hosting the JAVA Server 17, and is con- 
nected to the JAVA server 1 7 over a TCP/IP connection. 
[0018] The purpose of the Web server 16 is to com- 
municate with client browser software and to service re- 

35 quests for information transfers from the browser soft- 
ware. Several companies, such as MICROSOFT Cor- 
poration and NETSCAPE Communications Corporation 
provide Web Server software for a variety of computer 
platfomfis. 

40 [001 9] The JAVA server 1 7 manages sockets to com- 
municate with the JAVA applets running on the client 
browsers 26. It should be noted that while the present 
invention is discussed in connection with JAVA as a pro- 
gramming language used to convey information be- 

45 tween the client browsers and a telecommunications de- 
vice (in this case and SCP). other languages, either cur- 
rently available or later developed, could also be used. 
[0020] The domain name server 18 is a dynamic da- 
tabase which can be updated over the Internet/Data 

50 Network6 to provide enhanced services. Some of these 
services are described in U.S. Ser No. 09/201,460, en- 
titled "Method and Apparatus for Dynamic Domain 
Names" to Weser et al, filed November 30. 1 998 (based 
on U.S. Ser No. 60/067.231 . filed December 3. 1997). 

55 in U.S. Sen No. 09/201.248, entitled "Digital Phone Sys- 
tem' to Weser et al, filed November 30, 1 998 (based on 
U.S. Ser. No. 60/067,233, filed December 2, 1 997), and 
In U.S. Ser No. 60/096;487, entitled "Method and Ap- 
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paratus tor a Dynamic I LS", to Lee Jr. et al, filed August 
14, 1998, all of which are Incorporated by reference 
herein. 

[0021] The association between an IP address and a 
name in the dynamic domain name sen/er 18 may 
change based on any number of parameters. One such 
parameter would be time of day. An on -line catalog com- 
pany, for example, may direct orders during morning 
hours to a first web site with a first physical address and 
direct calls during afternoon hours to a second web site 
with a second physical address. 

[0022] Intelliyenl prucessrny of a dofnain name could 
be particularly useful In conjunction with digital phones 
which allow audio (and sometimes video) to be passed 
over an Internet connection. A digital phone connection 
over the Internet passes audio/video data packets be- 
tween two or more IP addresses. Digital phone connec- 
tions could be used in a number of commercial settings, 
such as on-line catalog services, where the customer 
may need to talk to a representative. The SCR 1 0 could 
direct a digital phone connection to one of a number of 
available service representatives at various locations. 
The digital phone connection could be based on time of 
day, current load, or other parameters, such as the us- 
er's ISP or local exchange carrier. This would allow a 
representative to work out of various locations, including 
for example, his or her house, with the SCP 1 0 directing 
the digital phone connections to the proper site. 
[0023] Another parameter which could be used in 
processing IP addresses is the location of the request- 
ing user. The IN Services could look up the address of 
a requesting user and connect the user to specific home 
page or digital phone based on the address. For exam- 
ple, a pizza chain may have a nationwide number. Once 
called, the dynamic database determines an IP address 
based on the ANI (automatic number identification) of 
the call, then uses that address to set up a digital phone 
connection with the location nearest the user. 
Other parameters which may be used to determine an 
IP address from the dynamic domain name sender 18 
include time, day of week, the user's telephone number, 
and other user profile information, such as age, gender, 
income and so on. Multiple parameters may be used in 
determining the IP address associated with a dynamic 
domain name. 

[0024] It should be noted that non-dynamic domain 
name servers, of the type typically used in the Internet 
to look up domain names, may cache addresses from 
the dynamic domain name server 18, which could alter 
the functionality of the dynamic nature of the dynamic 
domain name server 18. In order to prevent caching by 
other domain name servers, the dynamic domain name 
server 18 could pass a persistence parameter ("time to 
live" or TTL") equal to "0" along with the IP address. 
[0025] In operation, the SCP 10 is seen as a typical 
IN (intelligent network) capable SCP by the PSTN 
through TCAP over SS7/C7 connection 20. Further the 
SCP 10 can communicate with other devices over the 
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connection 22, through SLEE 12. Thus, if a PSTN de- 
vice requires service information from the SCP 10, it can 
retrieve it from database manager 14 through SLEE 12 
as usual. 

5 [0026] Other devices may obtain information from the 
dynamic domain name server 18 (and the database 
manager 14) from SCP through connection 22. In the 
illustrated embodiment, SLEE 12 communicates in the 
TCAP protocol. If communication using other protocols 
w is desired, translation software may be added to allow 
communication with other protocols. For example, using 
a pioyrarnrnable TCAP SLEE 12. an ISUP-to-TCAP 
converter could be used to allow communication with 
ISUP devices. The converter would add TCAP headers 
15 lo incoming messages and strip TCAP headers from 
outgoing messages. This would allow an existing pro- 
grammable message interface, such as the one found 
on the DSC INFUSION product, to be used in the SCP 
10. Alternatively, SLEE 12 could be capable of commu- 
nicating in a number of different protocols: similar to the 
SLEE discussed in connection with U.S. Ser No. 
60/086,971 , referenced above. 
[0027] Figure 2 illustrates a gatekeeper device 30. 
which is based on the architecture SCP 10 of Figures 
1 b and 1c. In an H.323 network, a gatekeeper has four 
primary functions. First, the gatekeeper performs ad- 
mission control; i.e., it determines whether or not a de- 
vice can originate or terminate a call. Second, the gate- 
keeper performs bandwidth control, which is defined in 
the RAS (Registration. Admission and Status) specifi- 
cation. Third, the gateway perfonms address translation 
from LAN aliases for terminals and gateways to IP or 
IPX addresses (also defined in the RAS specification). 
Fourth, a gatekeeper oversees all terminals, gateways 
and MCUs (multipoint control units) within its zone (re- 
ferred to as a Gatekeeper Zone). 
[0028] The gatekeeper 30 shown in Figure 2 is similar 
to the SCP 10 shown in Figures lb and 1c. but it adds 
an additional interface. UDF (user defined function) 
MSG interface 32. A UDF MSG is a user-defined SIB 
(service independent building block) which, in this case, 
handles control messages of the H.225 and H.245 pro- 
tocols specified under H.323. The UDF MSG interface 
is connected to a ULS (universal locator service) 34 
through a 225/RAS channel 36 and to one or more gate- 
ways 40 (described in greater detail in connection with 
Figure 3) through RAS channel 38. 
[0029] The ULS is software operated by a network 
provider in order to log in users with the appropriate pa- 
rameters. This software communicates directly with an 
Internet locator service of a server. The gatekeeper 30 
registers permanent IP addresses on the Internet/Data 
Network 6 when the user first accesses the network and 
registers dynamically assigned IP addresses with each 
dial up session (since the user may be assigned a dif- 
ferent IP address with each dial up session). 
[0030] In operation, the gatekeeper, in addition to its 
required and optional services under the H.323 stand- 
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ard can also function to generate connections between 
digital phoneS; between PSTN phones and digital 
phones, and between PSTN phones using the informa- 
tion in the dynannic DNS 18 as described in connection 
with Figures 1 b and 1 c. It should be noted that while the 
gatekeeper 30 of Figure 2 is shown incorporating both 
a Web server 16 and a JAVA server 1 7. it could similarly 
be configured with only a JAVA server 17 as shown in 
connection with the SCR of Figure 1 b. 
Figure 3 illustrates a gateway 40. A gateway is a termi- 
nal that interfaces between networks, for example, be- 
Iweer) an H.323 nelwojkand the PSTN. In the illuylialed 
embodiment, gateway 40 provides an interface point to 
the PSTN through ISUP connection 42 for call control 
and T 1 connection 44 for analog voice information. 13- 
UP/SS7 connection 42 is coupled to an ISUP MSG in- 
terface 44, which is coupled to SLEE 12. SLEE 12 in- 
cludes a UDF MSG interface 46 which is coupled to 
Voice-over-IP (VoIP) boards 48 along with the T1 line 
44. VoIP boards 48 include a control section 48a which 
recoivos H. 225/245 commands from the SLEE 12 
through the UDF MSG interface 46. SLEE 12 is also 
coupled to a database 50. 

[0031] The VoIP boards 48 are DSP (digital signal 
processor) boards which translate between analog 
voice signals on the T1 line and packetized (IP) audio 
signals on the InterneVData Network 6 under control of 
the control signals from the SLEE 12. The VoIP boards 
48 can also send H. 323 messages to the gatekeeper 30 
and to other H.323 devices. VoIP boards are available 
from a variety of vendors, including DIALOGIC Commu- 
nications Corporatbn. 

[0032] In operation, the gateway 40 provides an inter- 
face point to the PSTN through ISUP and bearer chan- 
nels. ISDN lines or the ATM backbone network. The ba- 
sic call state model (BCSM) is contained within an SLP 
to be executed on the gateway's SLEE for both the ISUP, 
ISDN or ATM side and the H.323 side of the call. Mes- 
sages from the ISUP/SS7 connection 42 are received 
by the ISUP MSG interface 44 (not necessary if the 
SLEE can receive ISUP signals directly) which wraps 
the messages in a TCAP header and passes the mes- 
sages to the SLEE. Similarly, when outbound messages 
are sent from the SLEE 12 to the ISUP/SS7 channel, 
the ISUP MSG interface strips the TCAP headers. 
[0033] On the H.323 side, the UDF MSG interface 46 
strips the TCAP header information from outbound mes- 
sages and re-encodes the messages using PER 
(Packed Encoding Rules). Inbound messages also pass 
through the UDF MSG interface 46, which changes the 
message from PER to BER (Basic Encoding Rules) en- 
coding prior to sending the message to the SLEE 1 2. 
[0034] Figure 4 illustrates a simplified block diagram 
of a communications system where the PSTN and an 
Internet/Data Network 6 are coupled to gateway 40. 
along with gatekeeper 30. Gatekeeper 30 is also cou- 
pled to other H.323 devices 52. In this embodiment, us- 
ers can create a communications channel between any 



combination of PSTN and H.323 devices (i.e., PSTN-to- 
PSTN, PSTN-to-H.323. or H.323-to-H.323). Further, 
multipoint communications between any combinatbn of 
devices is supported. 

5 [0035] For example, a user with only a PSTN device 
(i.e., a telephone) may call a number which is associated 
with a digital phone. This number would be sent in the 
PSTN to connect to gateway 40. Upon receiving the call, 
the gateway would be supplied with an ISUP message 

w including the number called (destination number), the 
calling party number and charge number The gatekeep- 
er 30 would proceed to deleirnine ttie IP address with 
which to form a connection. In this example, it will be 
assumed that the caller dials a number associated with 

15 a particular vendor, such as 1-800- FLOWERS. After 
registration and admission, the gateway 40 sends a 
message along with the destination number to the gate- 
keeper 30, requesting a look-up of the associated I P ad- 
dress. The gatekeeper 30 replies with routing informa- 

20 tion (an IP address and routing permission) to complete 
the call. As described above, the routing information de- 
termined by the gatekeeper 30 may be dependent upon 
a number of factors, including, for example, time of day, 
day of week, calling party number destination number. 

25 and available operators for this service. 

In an alternative method of connecting to a digital phone, 
the caller dials the number associated with gateway 40. 
The destination number does not indicate the final des- 
tination; once connected to the gateway 40, the user di- 

30 als a second number indicating the destination. The 
gateway 40, after registration and admission, passes 
this number to gatekeeper 30, which determines the IP 
address associated with the destination. 
[0036] Figure 5 illustrates an ISN (integrated service 

35 node) 60 for PSTN to PSTN communications. A first IS- 
UP-to-TCAP translator 62a is coupled to an ISUP con- 
nection of a PSTN switch and a first VoIP board 64a is 
coupled to an associated T1 line. A second ISUP-to- 
TCAP translator 62b is coupled to an ISUP connection 

40 of a PSTN switch and a second Vol P board 64b is cou- 
pled to an associated T1 line. A router 66 is coupled to 
the H.323 side of the VoIP boards 64a and 64b, and also 
to SRF (service resource funclbn) boards 68a-b and 
SCP 10. SCP 10 is also coupled to SRF boards 68a-b 

45 and to the ISUP-lo-TCAP translators 62a-b. 

[0037] In operation, when a connection is made, the 
voice signals from the bearer channel (T1 line) are trans- 
lated into a stream of data packets by the corresponding 
VoIP board 64. The connection can be made either by 

50 passing the audio packets th rough the router to another 
VoIP board or by routing the packets through the router 
66 back to the originating VoIP board. In either case, the 
packets are translated back into analog voice signals on 
the associated T1 line. 

55 [0038] While the voice signals are packetized, how- 
ever, the SRFs may control the data stream to play an- 
nouncements, collect digits, perform voice recognition 
(identification), speech totext conversbn, texttospeech 
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conversion, transfer packets to voicemail servers, per- 
form facsimile store and forward, and other functions 
normally associated with an SRF The SCP 10 can con- 
trol the connections as discussed in connection with Fig- 
ure 1. In the Illustrated embodiment the SCP 10 per- 
forms the BCSM functions and controls the SRF accord- 
ing to one or more SLPs executed in the SCP's SLEE. 
[0039] Figure 6 illustrates an IP (intelligent peripheral) 
70, which can be used in connection with the PSTN and 
H.323 network. The IP 70 includes an ISUP-to-TCAP 
translator 72 coupled to an ISUP connection from the 
PSTN and a VoIP boaid 74 uoupled to a conespondiny 
T1 line. The ISUP-to-TCAP translator 72 is coupled to 
an SCP 10. The SCP 10 is coupled to an SRF 78. The 
VoIP board 74 and the SRF are coupled to a router 76, 
which may be coupled to other H.323 devices 79 
[0040] In operation, calls are transferred to the tP 70 
as they would be in a normal PSTN scenario. The bearer 
channel is digitized and IP functions are added/re- 
moved/analyzed as packets, then decoded and placed 
on the bearer channel again. The call is then released 
back to the PSTN. The IP 70 can be concurrently used 
by an H.323 network at the same time. The SRF can 
perform a number of functions on the packetized infor- 
mation in the bearer channel, including playing an- 
nouncements, collecting digits from tones, performing 
voice recognition (Identificatbn). performing speech to 
text conversion, performing text to speech conversion, 
transferring packets to voicemail servers, performing 
facsimile store and forward, and other functions normal- 
ly associated with an SRF. 

[0041] Figures 7a-d illustrates a call center applica- 
tion which could be performed using the SCP 10 of Fig- 
ure 1 . This application is useful for commercial services 
over the Internet, or other data network, where custom- 
ers can request digital phone connection to operators of 
a vendor. The IP addresses associated with the opera- 
tors will change over time as operators start and stop 
work. Further, the available operators will change during 
the day as operators become busy with customers, take 
breaks and so on. The SCP 10 manages the connec- 
tions between customers and operators as efficiently as 
possible. 

[0042] The operator begins the login process by re- 
questing the login page from the web server via the In- 
ternet. This can be accomplished by entering an I ntemet 
address for the page. As sample operator login page is 
shown in Figure 7b, with input fields 200 and 202 for an 
operator name and password, and a submit button 204. 
The operator completes the login page by entering his 
or her name and password and presses the submit but- 
ton. A JAVA applet sends the data from the form to the 
SCP 10, either directly (if the web server 16 and JAVA 
server 17 are at the same site) or via a relay at the web 
server (if the web server 1 6 is at a different site, in order 
to comply with JAVA security constructs). Upon receiv- 
ing the data from the login form, the SCP 10 initiates 
operator-login service logic shown in blocks 90 and 92. 



The JAVA server 17 opens a socket and stores the data 
in the database 14 of the SCP 10. In block 92, Ihe op- 
erator sen/ice logic begins. The SLEE 12 reads the op- 
erator data from the database in block 94 and validates 

5 the operator. Assuming a proper name and password 
were entered by the ope rat on a confirmation page is 
sent to the operator in block 96. which monitors that op- 
erators status. A sample conflrmation/status page is 
shown in Figure 7c. In this embodiment, there are three 

10 buttons to allow the operator to indicate his or her 
present status: (1) Customer, for when the operator is 
busy wilfi a cuslornej, (2) Bieak. foi when the opeiator 
is not with a customer but is temporarily unavailable and 
(3) Available, for when the operator is ready to receive 

15 a call from a customer. The active button, in this case 
the "Available" button, is colored to indicate the current 
status to the operator. Other interfaces, with different in- 
put graphics and different status levels could be used in 
place of this screen, as would be known to one skilled 

20 In the art. Whenever a status button is pressed, the data 
is stored In block 9B. In block 102. control is handed to 
the UDF Listener 105. The UDF SIB 98 passes the cor- 
relation ID of the operator back to the JAVA server 17 
through the UDF Listener 105. The UDF Listener 105 

25 monitors different threads (multiple operators may be si- 
multaneously running the service logic). In block 103 
and 104, the JAVA server 17 collects data from the da- 
tabase and sends confimning information back to the op- 
erator 

30 [0043] Similarly, a customer can request a form page 
from a vendor via the Internet. For example, a user may 
be browsing a vendor's on-line catalog and wish to dis- 
cuss a product with a customer service operator. A sam- 
ple customer form page is shown in Figure 7d. Once the 

35 form page is completed and submitted by the customer, 
the JAVA applet on the customer's computer sends the 
data to the JAVA server 17 of the SCP 10, directly or 
indirectly, along with other information, such as the cus- 
tomer's IP address and browser type. 

40 [0044] The JAVA server 1 7 opens a socket to receive 
and store the data in block 1 06. The vendor service logic 
starts In block 108. In block 110, the SLEE opens the 
database 14 and validates the vendor Information in 
block 112, Assuming this is valid, the SLEE 12 collects 

45 the customer IP address, browser type and data from 
the form. In block 114, the assign operator routine be- 
gins, where the SLEE determines an active available 
operator. In block 11 6, the database is updated to reflect 
a busy operator, the start -time, and so on. In block 118. 

50 the UDF SIB is used to pass the correlation ID back to 
the JAVA server. In blocks 1 20 and 1 22, the JAVA server 
17 reads the database 14 and contacts the chosen op- 
erator with data concerning the customers IP address, 
browser type and form data. 

55 [0045] From this point, the operator can initiate a di- 
rect Internet connection with the customer via an appro- 
priate conferencing package, such as NETSCAPE 
CONFERENCE or MICROSOFT NETMEETING. When 
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the call is complete, the operator presses the "Available" 
button to update the status In block 96. 
[0046] The application described above does not re- 
quire a dynamic DNS. In an alternative architecture, the 
dynamic DNS 18 would be updated from a default mes- 
sage when the first operator logs in. Subsequent oper- 
ators would then be placed in a buffer prior to being ro- 
tate to the dynamic DNS 18. Customer inquiries could 
then be routed directly to operators using generic URLs, 
but without service logic capability associated with the 
customer. This scheme would impose operator actions, 
such ds accepliny oi uornplyling calls, to update oper- 
ator status. However, multiple messages from a custom- 
er to the same operator would be more difficult to sup- 
port. 

[0047] Figure B illustrates an SMS 1 30 (service man- 
agement system) to provide remote service manage- 
ment and provisioning functions by the OSS (operation 

support services). The SMS 1 30 is coupled to a redun- 
dant pair of SCPs 10. The SMS 130 includes a PSTN 
SMS 1 32 coupled to a master database 1 34. A web 
server 136 is coupled to the Internet or to another data 
network and to the master database through database 
connectivity software 138, such as JCONNECT from 
SYBASE, INC. A replication server 1 38 is coupled to da- 
tabases 1 4 of two redundant SCPs 1 0. The PSTN SMS 
is also coupled directly to the databases 1 4. 
[0048] In operation, the master database 134 could 
be modified through the PSTN SMS or through the web 
server 1 36. The replication server copies changes made 
to one of the databases 1 34 or 1 4, to the other databas- 
es, so that all databases are in sync with one another 
The SMS 1 30 altows users to provision and configure 
services via the Internet. For example, telephone. cus- 
tomers could add/delete/modify services over the Inter- 
net without intervention by telephone company or ISP 
personnel. Further, telephone company and ISP per- 
sonnel could perform service modifications over the In- 
ternet, providing more sophisticated HTML (hypertext 
markup language) and JAVA interfaces and allowing 
more personnel to work in a variety of locations. 
[0049] The devices described herein provide signifi- 
cant advantages over the prior an. First, the use of a 
programmable SLEE in the network devices provides 
for rapid devetopment and deployment of products and 
for flexible implementation of sen^ices. Second, the de- 
vices can be used to gain control of telephone calls, 
even those originating and/or terminating on the PSTN, 
in a digital domain. One particular embodiment of the 
capability would be in conference calling^ where callers 
could control the conference via a web browser. This 
would enable callers to have private conversations with 
another conference caller, and so on, while the confer- 
ence was ongoing, even if one or more of the partici- 
pants was connecting through the PSTN. The sen/ices 
are seamless to the users, who have the same function- 
ality whether independent of whether lines of communi- 
cation originate or terminate on the Internet or the 
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PSTN. Third, telephony services can be initiate via JAVA 
applets (or a similar software structure, wh'ch is prefer- 
able processor independent) which can enhance and 
simplify telecommunications sen/ices to users. 

5 

Claims 

1 . A telecommunications system comprising: 

10 

a public switched telephone system; 

a data netwoik (6), 

interface circuitry (7) coupled between said 
public switched telephone system and said da- 
15 la network (6) for translating between analog 

voice signals and a stream of packetized voice 
signals; 
and, 

control circuitry (8) coupled to said public 
20 switched telephone network and said data net 

work to control communication within and be- 
tween said public switched telephone system 
and said data network. 

25 2, A telecommunicatbns system according to claim 1 , 
wherein said data network (6) comprises the Inter- 
net. 

3. A telecommunications system according to claim 1 
30 or 2. wherein said control circuitry (8) includes: 

a database (50); and. 

a programmable execution unit (1 2) coupled to 
said database. 

35 

4. A telecommunications system according to claim 3, 
further comprising a language server coupled to the 
programmable execution unit (12) to communicate 
with applications executed on client terminals in 

40 said network. 

5. A telecommunications system according to claim 4, 
wherein said language server comprises a JAVA 
server (17). 

45 

6. A telecommunications system according to claim 4 
or 5, wherein said client terminals execute JAVA ap- 
plets running under browser software . 

50 7. A telecommunications system according to any of 
claims 4 to 6, wherein said language server initiates 
telephony services between the data network (6) 
and the public switched telephone network. 

55 8. A telecommunications system according to any of 
claims 4 to 7, wherein said language server initiates 
telephony sen/ices between the nodes on the data 
network (6). 
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9. A telecommunications system according to any of 
claims 4 to 8, wlierein said language server initiates 
telephony sen/ices between the nodes on the public 
switched telephone network. 

10. A telecommun ications system according toany pre- 
ceding claim, wherein said control circuitry (8) is op- 
erable to modify said stream of packetized voice 
signals. 

11. A service control point for use with a multimedia 
currununicatiun piotuuol. coinpiisiny. 
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19. A service control point according to any of claims 
11 to 17, wherein said programmable executran unit 
(1 2) is coupled to service resource function boards 
to operate as an intelligent peripheral (IP) device. 

20. A service control point according to claim 19, 
wherein said programmable execution unit (12) is 
further coupled to an I SUP to TCAP translator (62a, 
62b, 72). 
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a database (50); 

a database manager (14) coupled to said data- is 
base; 

a programmable execution unit (12) coupled to 
said database manager (14); and, 
a language server coupled to the programma- 
ble execution unit (1 2) to communicate with ap- 20 
plicatbns executed on client terminals coupled 
to said language server via a dala network. 

12. A service control point according to claim 1 1 , where- 
in said database comprises a domain name server 25 
(18). 

13. A service control point according to claim 12, 
wherein said domain name server (18) associates 
domain names and network addresses based on so 
current values 0I a pre-selected set of parameters. 

14. A service control point according to any of claims 
1 1 to 1 3, wherein said programmable execution unit 
(12) executes service togic programs. 

16. A service control point according to claim 14. 
wherein said execution of one or more of said serv- 
ice logic programs by said programmable execution 
unit (12) can be initiated by through the data net- 
work (6) via the language server 

16. A service control point according to any o( claims 
11 to 15, wherein said language server comprises 

a JAVA server (1 7) for communication with JAVA ap- 45 
plet executed on client terminals. 

17. A service control point according to any of claims 
11 to 16. further comprising a web sender (16) cou- 
pled to said language server and said client termi- so 
nals. 



18. A service control point according to any of claims 
1 1 to 1 7, wherein said programmable execution unit 
(12) is coupled to one or more universal locator 5S 
services for identifying an IP address associated 
with a user. 
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